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Abstract 

This  research  uncovers  areas  of  best  practices  that  support  achieving  alignment 
between  an  organization’s  Information  Technology  (IT)  and  its  business  processes.  One 
principal  finding  of  this  effort  revealed  that  the  means  used  to  achieve  alignment  exists 
within  the  effective  application  of  Enterprise  Architecture  (EA),  a  common  practice 
found  throughout  the  Federal  Government,  Department  of  Defense,  and  the  Air  Force. 
EA  is  the  tool  used  to  achieve  alignment;  likewise,  the  reason  for  developing  IT 
architecture  is  to  achieve  alignment  of  IT  investments  and  mission  objectives.  This 
research  groups  the  best  practices  into  vision,  identification,  framework,  and  governance. 
Interestingly,  these  practices  relate  to  an  Enterprise  Architecture’s  depiction  of  the  “to 
be”  target  state,  the  “as  is”  baseline,  the  tools  and  models  used  for  communication,  and 
the  motivation  and  management  of  the  “transition”  plan.  The  insights  achieved  by  this 
research  should  strengthen  the  use  of  Enterprise  Architecture  within  the  Air  Force  by 
enabling  senior  leaders  and  decision-makers  to  align  strategy  and  IT  investment  towards 
improving  mission  accomplishment. 
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ACHIEVING  ALIGNMENT:  AN  ANALYSIS  OF  ENTERPRISE  ARCHITECTURE 


BEST  PRACTICES  WITHIN  THE  UNITED  STATES  AIR  FORCE 


I.  Introduction 


Background 

The  use  of  Information  Technology  (IT)  in  the  workplace  has  become  as 
synonymous  as  the  world’s  use  of  the  wheel,  leaving  us  unable  to  picture  a  world  absent 
of  either.  Mutually,  they  create  a  facilitating  foundation,  the  wheel  contributing  to  the 
ease  of  movement,  and  IT  doing  its  part  on  our  use  of  infonnation.  Like  the  wheel's 
limited  beginnings  of  turning  pottery,  initial  implementations  of  IT  focused  on  dedicated 
purposes  resulting  in  silo  systems  whose  devoted  purpose  and  functionality  made  them 
inapplicable  to  other  aspects  of  the  organization.  As  can  be  seen  in  the  tiny  gears  of  a 
watch  or  in  the  construction  of  a  jet  engine,  progression  has  taken  the  wheel  and  turned  it 
into  an  intricate  part  of  a  greater  good.  IT  has  also  followed  a  similar  progression, 
shifting  its  advancement  from  a  capability  to  an  asset  used  to  structure  future  strategic 
opportunities  of  the  organization  (Ross,  Weill,  and  Robertson  2006). 

Conceptually,  the  wheel  itself  is  a  rather  simple  contraption.  However,  when 
combined  with  other  components  to  create  a  more  complex  system,  a  plan  is  necessary  to 
provide  structure  and  orderly  arrangement  of  the  inner-working  parts.  IT,  with  a  capacity 
to  be  ingrained  throughout  our  organizations,  requires  a  similar  planning  discipline 
known  as  architecture.  This  architecture  represents  the  “fundamental  organization  of  a 
system’s  components,  their  relationships  to  each  other  and  to  the  environment,  and  the 
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principles  guiding  its  design  and  evolution,”  (IEEE  2000).  Coincidently,  this  leaves  the 
act  of  architecting  to  be  relatively  known  as  “the  activities  of  defining,  documenting, 
maintaining,  improving,  and  certifying  proper  implementation  of  an  architecture,”  (IEEE 
2000). 

Knowing  where  to  begin  and  what  to  include  or  exclude  from  an  IT  architecting 
effort  requires  scoping  decisions  to  ensure  the  effective  representation  of  resources  and 
an  un- wasted  effort.  These  decisions  are  often  based  on  an  enterprise,  which  represents 
“an  organization,  or  cross-organizational  entity,  supporting  a  defined  business  scope  and 
mission”  (CIO  Council  2001).  The  organization’s  defined  business  scope  and  mission 
drives  the  effort,  encompassing  the  coordination  of  functions  and  shared  information 
within  a  particular  architecture.  Large  organizations  can  be  comprised  of  many  sub¬ 
enterprises  or  segments,  each  executing  their  individual  scope  and  mission,  as  well  as 
contributing  to,  and  existing  as,  part  of  a  larger  enterprise.  This  matryoshka  nested  doll 
effect  can  be  seen  within  the  Federal  Enterprise  Architecture  Federation  (FEAF) 
portrayed  in  Figure  1.  Encompassing  sub-enterprises  as  it  progresses,  the  FEAF  starts 
with  the  nesting  of  program  and  node  architectures  into  domain,  or  functional  areas  of 
responsibility  (e.g.  Finance,  Acquisition,  or  Logistics),  and  Major  Command  (MAJCOM) 
enterprises.  In  turn,  MAJCOM  and  domain  enterprises  nest  into  the  AF’s  service  level 
enterprise  architectures  of  Warfighting,  Agile  Combat  Support,  and  IT  Infrastructure. 
Topping  the  sequence  are  the  Department  of  Defense  (DoD)  and  federal  level  enterprises 
respectively.  A  nested  hierarchy  of  enterprises  as  described  by  FEAF  facilitates  the  flow 
of  guidance  and  represents  opportunities  for  content  reuse  (DAF  2007). 
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Figure  1 :  Federal  Enterprise  Architecture  Federation  (AFI  2007) 


Both  the  inevitable  advancement  of  technology  and  the  evolving  needs  of  a 

parenting  enterprise  depict  change.  To  facilitate  this  unavoidable  notion,  a  concept 

depicting  the  current,  target,  and  transitional  process  of  an  architecture  is  identified 

within  an  Enterprise  Architecture  (EA).  An  EA  represents: 

a  strategic  information  asset  base,  which  defines  the  mission,  the  information 
necessary  to  perform  the  mission,  the  technologies  necessary  to  perform  the 
mission,  and  the  transitional  processes  for  implementing  new  technologies  in 
response  to  the  changing  mission  needs  (CIO  Council  2001). 

EA  represents  the  logic  an  organization  follows  to  align  its  IT  and  systems  with 

its  processes.  This  produces  a  synergistic  application  of  business  strategy  coupled  by  the 

advantages  of  IT  application.  With  this  synergy,  the  predisposition  of  IT  representing 
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itself  as  a  liability  can  be  re-engineered  into  leveraging  the  achievement  of  mission 
accomplishment.  The  realization  of  this  benefit  is  apparent  by  the  mandate  to  architect 
our  federal  systems  and  enterprises. 

The  importance  of  alignment 

Driven  by  legislation  (US  Congress  1996)  and  the  expectation  of  leveraging 
Infonnation  Technology  (IT)  to  align  with  business,  the  Federal  Government  has  pursued 
the  act  of  Enterprise  Architecting  (EA)  for  over  a  decade.  Despite  the  amount  of  time 
that  has  lapsed,  the  EA  maturity  to  support  well  infonned  IT  decision-making  has  yet  to 
be  realized  (US  GAO  2002;  US  GAO  2008).  However,  not  a  new  or  government- 
specific  problem,  the  need  of  achieving  IT-business  alignment  has  plagued  the  minds  of 
IT  executives  from  all  industries  for  almost  thirty  years  (Luftman  and  Kempaiah  2007). 
With  the  desire  to  fill  this  need,  decision-makers  continually  search  for  best  practices  to 
help  with  the  alignment  of  their  IT  and  business  organizations  (Luftman  2004). 
Unfortunately,  a  clear  depiction  of  the  nature  of  alignment  is  not  among  the  results 
(Plazaola,  Flores,  Silva,  Vargas,  and  Ekstedt  2007). 

The  definition  of  alignment  reflects  the  application  of  “IT  in  an  appropriate  and 
timely  way,  in  hannony  with  business  strategies,  goals,  and  needs,”  (Luftman  2004). 
Ingrained  within  this  definition  is  a  dualistic  view  between  “how  IT  is  aligned  with  the 
business  and  how  business  should  or  could  be  aligned  with  IT,”  (Luftman  and  Kempaiah 
2007).  This  facet  of  alignment  stands  clear  amongst  those  hoping  to  attain  it.  Not  clear, 
however,  is  how  alignment  is  achieved,  managed,  and  maintained  (Plazaola  et  al.  2007). 
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Luckily,  we  do  not  have  to  define  nor  design  a  new  process  to  clear  the  muddy  waters, 
the  resolve  is  right  in  front  of  us. 

The  achievement  and  management  of  alignment  exists  within  the  very  same  entity 
eluding  our  Federal  Government  for  the  past  twelve  years,  EA.  The  complex  theories 
and  methodologies  surrounding  strategic  IT-business  alignment  can  foundationally  be 
bridged  to  EA  (Plazaola  et  al.  2007).  Words  synonymous  with  alignment,  such  as 
integrated,  cohesion,  and  linked  can  also  be  found  within  the  descriptions  of  EA’s 
prescribed  benefits  of  promoting  the  integration  of  systems,  avoiding  duplication,  and 
optimizing  mission  perfonnance  (US  GAO  2002). 

Numerous  directives  point  the  Air  Force  (AF)  towards  the  creation  and  use  of 
EAs  to  deliver  a  set  of  living  models  depicting  the  complex  relationship  of  current  and 
future  IT  within  an  organization.  However,  the  time  consuming,  resource  rich,  task  of 
architecting  an  enterprise  requires  a  pay-off.  Private-sector  organizations  incorporate 
EAs  in  hopes  to  realize  bottom-line  improvements.  Conversely,  the  Federal  Government 
is  comprised  of  other  driving  factors  making  it  difficult  to  determine  the  same  kind  of 
realization  of  such  an  effort. 

Within  the  Defense  Architecture  and  AF  Architecture  Repositories,  some  AF 
organizations  have  strived  to  obtain  compliance  with  the  set  directives  by  initiating  and, 
with  varying  levels  of  completion,  producing  architectural  products.  Assuming  these 
efforts  are  initiated  with  the  private  sector,  bottom-line  theoretical  uses  of  EA  in  mind, 
perhaps  a  common  theme  for  the  public  sector  is  “what  good  comes  from  architecting?” 
The  answer  to  this  quandary  is  the  alignment  of  the  organization’s  IT  with  its  mission. 
When  the  alignment  between  IT  and  business  is  sought,  EA  is  the  tool  used  to  define  how 
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that  relationship  is  achieved  (Ross  2003).  The  result  of  the  successful  execution  of  EA  is 
alignment.  This  research  illustrates  the  benefit  of  achieving  EA  alignment  by  providing 
foundational  research  towards  its  composition  as  well  as  assessing  the  ability  of  AF 
doctrine  to  instruct  and  assist  its  accomplishment.  The  single  and  recognizable  reference 
towards  EA  alignment  should  enable  decision  makers  to  apply  a  synergistic  application 
of  strategy  and  IT  towards  mission  accomplishment. 

Research  Objectives 

The  logic  of  EA,  with  its  goal  of  aligning  an  organization’s  IT  and  systems  with 
its  processes  to  produce  a  synergistic  application  of  business  strategy  coupled  by  the 
advantages  of  IT  application,  provides  a  map  to  the  executable  nature  of  alignment.  The 
similarities  between  these  perspectives  allude  to  alignment’s  ability  to  reflect  the  use  of 
EA.  IT  being  an  integral  part  of  mission  accomplishment  and  a  factor  the  United  States 
military  continually  strives  to  use  strategically,  a  portrayal  of  a  more  effective  enterprise 
requires  a  guideline  that  can  identify  EA  components  that  attribute  to  alignment.  Such  a 
guideline  will  aid  in  battling  the  perception  that  architectural  efforts  exist  as  a  non¬ 
revenue  producing  expense  or  an  endeavor  that  does  not  directly  attribute  to  mission 
accomplishment  as  well  as  entice  the  use  of  architectures  by  promoting  the  feat  of 
alignment.  This  research  accomplishes  this  endeavor  by  answering  the  research 
questions  surrounding  the  concept  of  EA  alignment: 

1 .  What  Enterprise  Architecture  best  practices  attribute  to  the  successful 

achievement  of  alignment? 
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2.  What  Air  Force  policy  and  guidance  prescribes  and  describes  Enterprise 
Architecture  usage? 

3.  Does  the  Air  Force  Enterprise  Architecture  policy  and  guidance  adequately 
capture  the  concept  of  alignment? 

Thesis  Organization 

This  research  is  directed  towards  DoD  architects,  IT  program  managers,  Chief 
Information  Officers  (CIO),  their  staff,  and  executives.  It  serves  as  a  guide  depicting  the 
necessary  aspects  of  EA  that  contribute  to  its  successful  execution,  alignment.  The 
remainder  of  this  thesis  will  report  the  efforts  taken  to  address  the  research  questions. 
Chapter  II  provides  a  literature  review  of  best  practices  surrounding  the  creation  of  a 
useful  EA,  a  factor  of  EA  mostly  covered  by  literature  (Lagenberg  and  Wegmann  2004). 
Chapter  III  describes  and  analyzes  AF  EA  guidance  on  their  inclusion  of  described  best 
practices.  Chapter  IV  applies  the  described  best  practices  onto  a  representative  IT 
project,  providing  a  depiction  of  the  implementation  of  alignment  capturing  best 
practices.  Chapter  V  summarizes  the  research  by  presenting  the  researcher’s  conclusions 
and  recommendations. 
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II.  Literature  Review 


Overview 

In  this  chapter,  a  literature  review  is  conducted  relevant  to  the  research  topics 
found  to  contribute  to  the  successful  creation  and  execution  of  EA.  The  review 
indentified  several  similarities,  which  allowed  for  a  taxonomy  amongst  these  concepts,  as 
illustrated  in  Figure  2.  The  best  practices  that  have  shown  to  contribute  to  the  successful 
creation  and  execution  of  EA  are  vision,  identification,  framework,  and  governance. 


Vision 


Alignment 


Figure  2:  Taxonomy  of  EA  Best  Practices  Attributing  to  Alignment 
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Vision 


Architectures  are  created  to  provide  something  of  worth.  Their  result  provides  a 
means  to  an  end  that  should  result  in  better  decision-making.  The  resourceful  nature  of 
this  capability  requires  a  vision.  The  vision  of  an  EA  effort  is  unique  to  the  owning 
organization.  It  ensures  all  collaborators  are  synchronized  in  knowing  the  stakeholders, 
the  problems,  the  priorities,  and  any  common  IT  standards  and  tools  (Armour,  Kaisler, 
and  Liu  1999b). 

The  vision  defines  the  business  strategy  of  the  organization  and  depicts  how  the 
enterprise  will  use  IT  in  support  of  that  strategy  (Armour,  Kaisler,  and  Liu  1999a).  One 
method  of  selecting  this  vision,  yielding  a  17  percent  enhancement  over  strategic 
effectiveness,  involves  the  use  of  an  operating  model  (Ross  et  al.  2006).  Not  clearly 
defining  or  selecting  an  operating  model  that  does  not  fit  results  in  an  organization  that 
jumps  from  one  initiative  to  another  without  the  potential  of  leveraging  reusable 
capabilities.  By  selecting  an  appropriate  level  of  standardization  against  an  appropriate 
level  of  integration,  the  organization  “enables  IT  to  become  a  proactive — rather  than 
reactive — force,”  (Ross  et  al.  2006). 

Table  1  represents  the  characteristics  of  four  operating  models  an  organization 
may  choose  to  drive  their  strategic  initiatives.  The  Diversification  operating  model, 
consisting  of  low  business  process  integration  combined  with  low  business  process 
standardization,  refers  to  organizations  whose  business  units  are  related,  but  not 
integrated.  These  business  units  have  few,  if  any,  shared  customers,  suppliers,  or  ways  of 
doing  business.  The  Coordination  operating  model  identifies  an  organization  with  high 
levels  of  business  process  integration  but  low  levels  of  business  process  standardization. 
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Business  units  of  a  Coordination  organization  generally  share  customers,  products, 
suppliers,  or  partners  and  while  their  processes  are  integrated,  these  units  often  require 
unique  capabilities.  This  operating  model  cultivates  process  proficiency  as  well  as 
enhances  customer  service.  The  Replication  operating  model  allows  business  units  to  be 
self  sufficient  of  their  transactions  and  data  but  requires  operations  to  be  performed  in  a 
highly  standardized  manner.  Success  in  this  type  of  organization  relies  on  efficient, 
repeatable  business  processes.  The  Unification  operating  model  consists  of  highly 
integrated  business  units  with  a  standardized  set  of  processes.  Business  units  of  this  type 
of  organization  benefit  little  from  self-sufficiency  and  create  efficiencies  through 
integrated  data  as  well  as  by  removing  the  variability  out  of  processes  (Ross  et  al.  2006). 


Table  1 :  Characteristics  of  the  Four  Operating  Models  (Ross  et  al.  2006) 


Coordination 

•Shared  customers,  products,  or  suppliers 
•Impact  on  otherbusiness  unit  transactions 
•Operationally  unique  buisiness  units  or  functions 
•Autonomous  buisiness  management 
•Business  unit  control  over  business  process 
design 

•Shared  customer/sipplier/product  data 
•Concensus  processes  for  designing  IT 
infrastructure  services;  IT  application  decisions 
made  in  business  units 

Unification 

•Customers  and  suppliers  may  be  local  or  global 
■Globally  integrated  business  processes  often  with 
support  of  enterprise  systems 
•Business  units  with  similaror overlapping 
operations 

■Centralized  management  often  applying 
functional^roces  s/busi  ness  unit  matrices 
•High-level  process  owners  design  standardized 
processes 

•Centrally  managed  databases 
■IT  decisions  made  centrally 

Diversification 

•Few,  if  any,  shared  customers  orsuppliers 
•Independent  transactions 
•Operationally  unique  business  units 
•Autonomous  business  management 
•Business  unit  control  over  business  process 
design 

■Few data  standards  across  business  units 
•Most  IT  decisions  made  within  business  units 

Replication 

•Few,  if  any,  shared  customers 

•Independent  transactions  aggregated  at  a  high 

level 

•Operationallysimilarbusiness  units 
•Autonomous  business  unit  leaders  with  limited 
discretion  over  processes 
•Centralized  (or  federal)  control  overbusiness 
process  design 

•Standardized  data  defintions  but  data  locally 
owned  with  some  aggregation  at  corporate 
■Centrally  mandated  IT  services 

Low  High 


Business  process  standardization 
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Identification 


Identification  involves  defining  the  current  capabilities  of  the  organization’s 
business  processes  and  IT.  Enabling  descriptions  of  IT  competency  would  include  IT 
being  involved  in  the  development  of  the  strategy,  IT  understanding  the  business,  and 
well  prioritized  IT  projects  (Luftman,  Papp,  and  Brier  1999).  Identification  is  the  starting 
point  of  architectural  artifact  creation  and  exhibits  the  relationships  information  holds 
throughout  the  enterprise.  Through  the  discovery  of  hardware,  software,  and 
infrastructure  components,  potential  process  effecting  capabilities  such  as  the  discovery 
of  data  repositories  and  system  availability  becomes  apparent  (Annour  et  al.  1999b). 

Other  aspects  of  identifying  IT  capabilities  allow  an  organization  to  define  a 
target,  which  it  can  tenaciously  pursue.  As  change  progresses  and  new  opportunities 
prevail,  the  organization  “needs  to  redesign  and  then  implement  new  systems,  processes, 
and  IT  infrastructure  without  sabotaging  daily  operations,”  (Ross  et  al.  2006).  Depicting 
the  progression  that  organizations  follow  is  a  common  approach  known  as  the  “four 
stages  of  architecture  maturity,”  (Ross  et  al.  2006).  Within  this  trend,  each  stage 
represents  a  realization  on  how  to  steer  an  organization’s  current  IT  identification 
towards  strategic  capabilities.  Descriptions  of  the  four  stages  of  EA  maturity  are: 

•  Business  Silos  architecture:  where  companies  look  to  maximize  individual 
business  unit  needs  or  functional  needs 

•  Standardized  Technology  architecture:  providing  IT  efficiencies  through 
technology  standardization  and,  in  most  cases,  increased  centralization  of 
technology  management 
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•  Optimized  Core  architecture:  which  provides  companywide  data  and  process 
standardization  as  appropriate  for  the  operating  model 

•  Business  Modularity  architecture:  where  companies  manage  and  reuse  loosely 
coupled  IT-enabled  business  process  components  to  preserve  global  standards 
while  enabling  local  differences  (Ross  et  al.  2006) 

It  is  apparent  that  the  differences  between  these  stages  create  increased  strategic 
opportunities.  For  example,  the  Business  Silos  stage  allows  applications  to  align 
naturally  with  a  business  unit  or  function.  The  Standardized  Technology  stage 
establishes  standards  that  decrease  the  number  of  system  platforms,  lowering  cost.  The 
Optimized  Core  stage  allows  organizations  to  create  an  enterprise  view  of  data  and 
applications  stimulating  the  reusability  of  those  assets,  and  the  Business  Modularity  stage 
allows  for  strategic  agility  through  customized  modules,  providing  a  platform  for 
innovation  (Ross  et  al.  2006).  However,  organizations  are  cautioned  not  to  rush  through 
these  stages  as  they  represent  a  natural  progression  that  also  requires  increased 
management  and  governance  processes.  Trying  to  implement  one  without  the  other  can 
result  in  failures  and  delayed  benefits.  It  is  also  important  to  keep  in  mind  that  large 
complex  enterprises  may  consist  of  multiple  segmented  architectures,  each  with  its  own 
maturity  (Ross  2003).  Here,  an  implementation  of  a  technology  from  the  enterprise  level 
may  be  right  for  a  particular  segment  of  the  business,  but  detrimental  to  others  (Rehkopf 
and  Wybolt  2003). 
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Framework 


Two  problems  exist  when  attempting  to  design  and  use  the  architecture  of  an 
enterprise.  The  first  problem  stems  from  the  natural  propensity  to  model  everything. 

This  continual  analysis  of  extraneous  architecture  artifacts  stifles  progression,  hindering 
EA  effectiveness  (Annour  et  al.  1999b).  The  second  problem  is  the  tendency  to  model 
the  enterprise  piece-by-piece,  system-by-system  (Zachman  1997).  An  EA  should  convey 
the  big  picture;  it  is  a  system  of  systems  view  of  the  relationships  between  an 
organization’s  primary  resources,  reflecting  how  they  integrate  to  drive  the  strategy  of  the 
enterprise  (Anaay  and  Ortiz  2005;  Annour  et  al.  1999b).  Capturing  this  point  of 
reference  often  requires  EA  to  be  depicted  by  multiple  representations,  perspectives,  or 
viewpoints.  There  is  a  need  for  consistency  within  this  step.  Facilitating  this  unifonnity 
involves  using  “a  resource  that  aids  in  the  development  or  description  of  an  architecture,” 
a  characterization  found  within  an  architecture  framework  (Siegers  2004). 

An  EA  framework  can  assist  with  the  capture  of  involved  viewpoints  by  reflecting 
the  assessment  of  the  Who,  What,  When,  Where,  Why,  and  How  surrounding  a  process. 
Different  viewpoints  construed  from  the  same  entity  reflect  the  relationships  surrounding 
that  entity  (Zachman  1999).  Several  well-established  frameworks  are  in  use  today,  each 
with  overlapping  and  differentiating  aspects.  Generally,  dissimilarities  between  these 
frameworks  reflect  the  specific  needs  or  concerns  of  the  respective  realms  of  business 
from  which  they  are  applied  (Urbaczewski  and  Mrdalj  2006).  EA’s  multi-faceted  nature 
causes  it  to  be  characterized  as  an  art  as  well  as  a  science.  The  science  of  EA  lies  within 
solution  and  method-based  methodologies  represented  by  experimented  and  easily 
certified  results,  which  are  found  within  the  standards  that  define  its  capabilities  and 
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scientific  principles  that  support  its  methods.  The  art  of  EA  can  be  seen  within  the 
consensus  of  brainstorming  and  lessons  learned.  This  reflects  a  process  of  insight, 
intuition,  and  common  sense  that  portrays  an  individualistic  aspect  reflected  amongst  its 
products  (Maier  and  Rechtin  2002).  The  chosen  EA  framework  is  less  important  than  the 
information  and  relationships  it  captures.  Table  2  represents  the  focus  of  several  popular 
frameworks. 


Table  2:  Focus  of  Various  Architecture  Frameworks  (Siegers  2004) 


Framework 

Emphasis 

What’s  There 

What’s  Not  There 

DoDAF 

Product 

Definition 

A  set  of  26  architecture  products  grouped 
into  4  architecture  perspectives/views. 

No  detailed  methodology  guidance 

TOGAF 

Methodology 

In-depth,  step-by-step  instruction  for 
‘how  to'  architect 

No  required  architecture  products 

Zachman 

Classification/ 

Organization 

Schema  for  categorization  of  ‘primitive’ 
architecture  information 

No  required  architecture  products 

No  methodology  guidance 

IAF 

Classification/ 

Organization 

Schema  for  categorization  of  architecture 
information  with  apparent  Zachman 
influence 

Proprietary  framework;  scope  not 
known 

FEAF 

Architecture 

Components 

Broad  descriptions  of  the  necessary 
elements  of  an  architecture  and  numeric 
indicators  of  the  architecture 
documentation's  robustness 

No  specific  architecture  products 

No  methodology  guidance 

The  framework  an  enterprise  uses  should  accommodate  the  organization’s  vision. 
This  may  require  a  comparison  and  contrasting  of  frameworks  in  order  to  find  the  one 
that  provides  the  best  fit  (Urbaczewski  and  Mrdalj  2006).  Organizations  also  have  the 
option  of  merging  existing,  or  creating  new,  aspects  to  their  frameworks.  Examples  of 
this  would  be  adding  new  viewpoints  to  the  framework  to  account  for  enterprise  security 
or  the  rationale  behind  the  need  for  change  (Kreizman  and  Robertson  2006;  Robi  2004). 
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Governance 


Creating  the  right  environment  to  allow  the  EA  to  work  for  the  organization  is 
essential.  An  effective  management  structure  should  surround  the  act  of  architecting  as 
well  as  the  execution  of  the  IT  projects.  Creating  a  foundation  for  IT  project  change 
management  structured  around  using  EA  requires  senior  management  commitment  and 
support  of  IT.  This  type  of  commitment  and  support  should  also  establish  a  common 
understanding  that  is  communicated  frequently  (Annour  et  al.  1999b;  Luftman  et  al. 

1999;  Armour  et  al.  1999a;  Rehkopf  and  Wybolt  2003).  These  are  aspects  of 
governance.  Also  reflecting  governance  is  the  realization  of  the  importance  of  the 
architecture  team.  Consisting  of  multiple  backgrounds  and  skill  sets,  this  group  requires 
support  as  well  as  organizational  freedom  (Armour  et  al.  1999a;  Annour  et  al.  1999b). 

Effective  governance  relates  to  the  management  and  use  of  IT  within  the 
organization.  It  depicts  “the  decision  rights  and  accountability  framework  for 
encouraging  desirable  behaviors  in  the  use  of  IT,”  (Ross  et  al.  2006). 

Governance  does  not  consist  of  doctrine  alone;  it  is  based  on  the  organization’s  chosen 
operating  model,  or  vision,  reflecting  how  it  operates.  EA  governance  indicates  the 
organizing  logic  for  business  processes  and  IT,  enabling  the  alignment  of  these  two 
entities  (Ross  et  al.  2006). 

The  level  of  governance  required  to  be  effective  can  be  related  to  the  architectural 
maturity  of  the  organization.  Figure  3  depicts  the  type  of  governance  necessary  as  an 
organization  progresses  through  the  “four  stages  of  architecture  maturity”  described 
within  the  identification  best  practice.  Harmonizing  the  type  of  governance  within  the 
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architecture’s  maturity  represents  the  capability  of  strategically  capturing  alignment 
(Ross  et  al.  2006). 


Corresponding  type  of 
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Optimized  Core 
Architecture 


•  Align  project  priorities  with 
architecture  objectives 


Business  Modularity 
Architecture 


•  Define,  source  and  fund 
business  modules 


Figure  3:  Type  of  Governance  Needed  to  Correspond  with  Architecture  Maturity 
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Summary 

This  chapter  identified  an  aggregation  of  EA  best  practices  attributing  to  the 
successful  execution  of  alignment.  The  literature  search  uncovered  many  other  factors 
concerning  aligmnent  including  the  creation  of  systematic  processes  around  assessment 
and  maturity  models  and  the  construction  of  heuristics  around  dimensions  of  the 
organization.  However,  greater  emphasis  and  regularity  was  found  surrounding  the 
chosen  four  topics.  It  is  through  the  accommodation  of  vision,  identification,  framework, 
and  governance  that  an  organization  can  drive  “IT  capabilities  to  shape  business  strategy 
while  business  strategy  shapes  IT  capabilities,”  (Ross  2003).  Allowing  these  factors  to 
facilitate  an  architectural  effort  establishes  an  effective  EA,  providing  an  executable  map 
towards  alignment. 
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III.  Air  Force  EA  Guidance  Analysis 

Overview 

The  literature  review  of  the  last  chapter  identified  a  collection  of  EA  best 
practices  contributing  to  alignment.  The  best  practices  were  extracted  from  the  EA  body 
of  knowledge,  where  their  usage  was  studied  and  effective  results  verified  and  reported. 
A  comparable  amount  of  attention  has  been  aimed  towards  EA  within  the  public  sector. 
This  attention  has  resulted  in  a  considerable  amount  of  EA  doctrine  and  activity  from 
amongst  the  multiple  levels  of  the  Federal  Government,  based  on  EA  theory  that  is 
constantly  maturing  through  experimentation  and  practice.  The  direction  of  this  research 
will  now  focus  on  Air  Force  implementation  by  first  identifying  and  describing  the 
doctrine  that  describes  and  prescribes  EA  use,  and  second,  by  analyzing  their  ability  to 
capture  the  essence  of  aligmnent. 

EA  Guidance  Summary 

Guidance  affecting  the  Federal  Government  is  structured  in  a  hierarchical  manner 
where  legislation  and  federal  policies,  instilling  areas  of  compliance,  are  supplemented 
by  subordinate  policy  and  instruction  until  it  reaches  an  implementation  level.  The 
guidance  surrounding  EA  use  originates  from  federal  law  where  it  is  complemented  by 
the  Office  of  Management  and  Budget  (OMB),  the  Chairman  Joint  Chiefs  of  Staff,  the 
DoD,  Air  Force  Policy,  and  finally  by  Air  Force  Instruction  (AFI).  Figure  4  illustrates  a 
sample  of  the  guidance  examined  by  this  analysis. 
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Federal  Level 
Guidance 


DoD  Level 
Guidance 


AF  Level 
Guidance 


Figure  4:  Sample  List  of  Guidance 


Federal  Level  EA  Guidance 

The  importance  of  structuring  IT  towards  organizational  missions  and  goals  has 
been  realized  as  far  back  as  1996.  The  Clinger-Cohen  Act  (CCA),  also  identified  as  the 
Information  Technology  Reform  Act,  directs  federal  agencies  to  establish  a 
comprehensive  approach  towards  managing  their  IT  to  maximize  its  use.  The  CCA 
stipulates  that  before  the  investment  in  performance  supporting  IT  is  made,  the  processes 
surrounding  agency  missions  must  be  reengineered  to  ensure  they  support  operational 
goals.  A  reengineered  process  ensures  effective  use  of  the  acquired  IT,  where  goals  can 
be  established  to  improve  the  efficiency  and  effectiveness  of  those  operations  (US 
Congress  1996).  Central  to  implementing  the  transformations  called  for  by  the  CCA  is 
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the  establishment  of  IT  leadership  within  federal  agencies,  a  feat  accomplished  by 
instructing  the  designation  of  a  Chief  Infonnation  Officer  (CIO).  Concerning  EA,  the 
CIO  is  responsible  for  “developing,  maintaining,  and  facilitating  the  implementation  of 
sound  and  integrated  information  technology  architecture,”  (US  Congress  1996).  The 
definition  of  “information  technology  architecture”  refers  to  “an  integrated  framework  for 
evolving  or  maintaining  existing  information  technology  and  acquiring  new  infonnation 
technology  to  achieve  the  agency’s  strategic  goals  and  information  resources 
management  goals,”  which  is  concurrent  with  today’s  definition  of  an  EA  (US  Congress 
1996). 


The  CCA  also  directs  responsibility  onto  the  Office  of  Management  and  Budget 

by  instructing  their  use  of  performance  and  results-based  management  within  the 

acquisition,  use,  and  disposal  of  information  technology  within  the  Federal  Government. 

Accommodating  this  requirement,  the  OMB  established  Circular  number  A- 130, 

Management  of  Federal  Information  Resources,  for  the  insight  of  federal  information 

resources.  One  assumption  made  by  A- 130  is: 

Strategic  planning  improves  the  operation  of  government  programs.  The  agency 
strategic  plan  will  shape  the  redesign  of  work  processes  and  guide  the 
development  and  maintenance  of  an  Enterprise  Architecture  and  a  capital 
planning  and  investment  control  process.  This  management  approach  promotes 
the  appropriate  application  of  Federal  information  resources  (OMB  2000). 

A- 130  describes  an  EA  to  portray  “the  ‘current  architecture’  and  ‘target  architecture’  to 

include  the  rules  and  standards  and  systems  lifecycle  infonnation  to  optimize  and 

maintain  the  environment  which  the  agency  wishes  to  create  and  maintain  by  managing 

its  IT  portfolio,”  (OMB  2000).  According  to  A-130,  an  EA  exists  to  represent  the 

“explicit  description  and  documentation  of  the  current  and  desired  relationships  among 
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business  and  management  processes  and  information  technology,”  (OMB  2000). 
Concerning  the  EA  effort,  A- 130  facilitates  the  creation  or  use  of  an  EA  framework  to 
“document  linkages  between  mission  needs,  information  content,  and  information 
technology  capabilities,”  and  to  “guide  both  strategic  and  operational  IRM  planning,” 
(OMB  2000).  Through  a  framework,  the  EA  can  then  be  used  to  identify  and  document 
business  processes,  identify  information  flow  and  relationships,  and  capture  the 
applications,  data  descriptions,  and  technology  infrastructure.  Compliance  with  the 
criteria  contained  within  A-130,  summarized  in  Figure  5,  provides  the  OMB  with 
consideration  for  continued  or  new  IT  investments  (OMB  2000).  Additional  OMB 
Enterprise  Architecture  prescriptive  guidance  can  also  be  found  in  Circular  number  A-l  1, 
Preparation,  Submission,  and  Execution  of  the  Budget.  A- 1 1  states  that  the  budget 
“estimates  should  reflect  your  efforts  and  planned  action  to  strengthen  management  and 
improve  program  performance,”  and  that  these  “estimates  should  prioritize  and  manage 
E-Govemment  projects  effectively  through  your  agency’s  capital  planning  process  and 
enterprise  architecture,”  (OMB  2008).  It  goes  on  to  state  that  one  way  to  ensure  IT 
investments  improve  program  performance  is  to  ensure  it  supports  the  Federal  Enterprise 
Architecture  (FEA)  (OMB  2008). 


Guide 

Architecture 

Development 


Figure  5:  OMB  Strategic  Planning 
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Providing  various  methodologies  to  communicate  the  organization  and 
relationships  of  components  needed  to  develop  and  maintain  the  FEA,  the  CIO  Council 
developed  the  Federal  Enterprise  Architecture  Framework  (FEAF)  as  a  tool  to  engage 
federal  architecture  concepts  and  issues  (CIO  Council  1999).  The  FEAF  is  an  EA 
description,  representing  “a  conceptual  model  that  begins  to  define  a  documented  and 
coordinated  structure  for  cross-cutting  business  and  design  developments  in  the 
Government,”  and  supports  interoperability  and  reuse  of  infonnation  amongst  common 
processes  within  federal  agencies  and  governmental  entities  (CIO  Council  1999). 
Capturing  sub-architectures,  the  framework  is  structured  in  a  segmented  manner  where 
focus  is  placed  on  major  business  areas  allowing  for  “incremental  development  of 
architecture  segments  within  a  structured  enterprise  architecture  framework,”  (CIO 
Council  1999).  Collectively  the  interoperable  federal  segments  comprise  the  FEA. 

FEAF  utilizes  eight  components  that  the  CIO  council  found  necessary  to  develop 
and  maintain  the  Federal  Enterprise  Architecture.  Descriptions  of  those  components, 
illustrated  in  Figure  6,  are: 

•  Architecture  Drivers :  Represents  an  external  stimulus  that  causes  the  Federal 
Enterprise  Architecture  to  change 

•  Strategic  Direction :  Ensures  that  changes  are  consistent  with  the  overall  federal 
direction 

•  Current  Architecture:  Represents  the  current  state  of  the  enterprise 

•  Target  Architecture:  Represents  the  target  state 
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•  Transitional  Process :  Apply  the  changes  from  the  current  architecture  to  the 
target  architecture  in  compliance  with  the  architecture  standards,  migration 
planning,  budgeting,  and  configuration  management  and  engineering  change 
control 

•  Architectural  Segments :  Focus  on  a  subset  or  a  smaller  enterprise  within  the  total 
Federal  Enterprise 

•  Architectural  Models :  Provide  the  documentation  and  the  basis  for  managing  and 
implementing  changes  in  the  Federal  Enterprise 

•  Standards :  Include  standards,  voluntary  guidelines,  and  best  practices,  all  of 
which  focus  on  promoting  interoperability  (CIO  Council  1999) 

To  assist  capturing  the  complexity  of  these  components,  FEAF  employs  a  decomposition 
process,  breaking  the  framework  into  four  progressive  stages.  The  breakdown  provides 
an  understandable  frame  of  reference  that  increases  in  detail  as  one  progresses  the  levels 
and  ends  with  a  “logical  structure  for  classifying  and  organizing  the  descriptive 
representations  of  the  Federal  Enterprise,”  (CIO  Council  1999). 
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Figure  6:  Federal  EA  Framework  Components  (CIO  Council  1999) 


Two  other  EA  descriptive  documents  are  available  from  the  Office  of 
Management  and  Budget.  The  first,  titled  FEA  Consolidated  Reference  Model 
Document,  stems  from  the  OMB ’s  Office  of  E-Government  (E-Gov)  and  Information 
Technology  and  contains  a  description  of  the  architectural  models  component  identified 
in  FEAF.  Coined  as  reference  models  within  the  document,  they  collectively  “describe 
important  elements  of  the  FEA  in  a  common  and  consistent  way,”  (OMB  2007a).  The 
second  document,  titled  FEA  Practice  Guidance,  originates  from  the  Federal  Enterprise 
Architecture  Program  Office  of  the  OMB.  This  document  further  describes  the  FEAF’s 
segmented  approach  to  architecture  as  well  as  guidance  for  developing  and  using  an  EA 
transition  strategy.  The  Practice  Guidance  also  includes  a  description  of  methods 
dedicated  towards  the  capturing  and  measuring  of  the  value  of  EA  efforts.  As  “EA 
should  deliver  results-oriented  products  and  services  to  inform  business  decision  and 
increase  the  efficiency  and  effectiveness  of  IT  investments,  program  management  and 
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agency  operations,”  methods  such  as  these  are  needed  to  provide  a  metric  that  represents 
value  as  well  as  to  identify  EA  shortfalls  and  areas  for  improvement  (OMB  2007b). 

Department  of  Defense  Level  EA  Guidance 

Instructing  the  joint  environment  with  the  overarching  policy  to  “develop, 
acquire,  deploy,  and  maintain”  IT,  the  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 
(CJCSI)  62 12.0  IE,  Interoperability  and  Supportability  of  Information  Technology  and 
National  Security  Systems,  requires  EA  usage  to  achieve  compliance  and  Joint  Staff 
Interoperability  and  Supportability  certification.  This  guideline  requires  that  these 
architectures  meet  the  operational  needs  of  our  forces,  are  interoperable  with  existing  and 
proposed  systems,  are  supportable  via  the  Global  Infonnation  Grid  (GIG),  are 
interoperable  with  our  allies  and  coalition  partners,  protect  mission  data,  and  utilize  a 
common  language.  CJCSI  62 12.0 IE  directs  military  services  and  defense  agencies  to 
register  a  scope  and  content  or  vocabulary  view  of  their  enterprise  architecture  into  the 
established  DoD  Architecture  Registry  System  (DARS)  where  interoperability  and 
stakeholder  analysis  can  take  place.  CJCSI  62 12.0 IE  stresses  “interoperability  hinges  on 
the  alignment  of  enterprise  architectures  and  solution  architectures,”  enabling  a  “more 
detailed  analysis  of  the  information  requirements,”  (CJCS  2008). 

Establishing  policy  for  DoD  IT  management,  DoD  Directive  8000.1,  Management 
of  DoD  Information  Resources  and  Information  Technology,  directs  all  DoD  components 
to  have  a  reporting  CIO  who  ensures  accurate  and  consistent  infonnation  is  available  to 
decision-makers  in  execution  of  the  DoD  mission.  In  support  of  this  mandate  an: 
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integrated  DoD  architecture  with  operational,  system,  and  technical  views 
shall  be  developed,  maintained,  and  applied  to  determine  interoperability  and 
capability  requirements,  promote  standards,  accommodate  the  accessibility  and 
usability  requirements  of  reference,  and  implement  security  requirements  across 
the  DoD  en  terprise  to  provide  the  basis  for  efficien  t  and  effective  acquisition  and 
operation  of  IT  capabilities  (DoD  2002b). 

Establishing  an  environment  surrounding  the  DoD  enterprise,  Directives  8100.01,  Global 

Information  Grid  Overarching  Policy,  and  4630.05,  Interoperability  and  Supportability 

of  IT  and  National  Security  Systems,  assign  the  responsibility  of  ah  DoD  IT  missions 

support  to  fall  under  the  Global  Information  Grid  (GIG)  governing  entity.  The  GIG  is 

directed  to  consist  of  a  sound  and  integrated  architecture,  and  the  architected  assets 

falling  under  its  umbrella  will  comply  with  the  components  of  the  GIG’s  Architecture  to 

sustain  a  consistent  and  interoperable  DoD  enterprise  (DoD  2002a).  The  result  of  this 

effort  is  intended  to  provide  decision  superiority  to  the  warfighter  and  decision-maker  by 

creating  a  construct  that  allows  for  net-centric  operations  and  warfare  (DoD  2004). 

Understandably,  architectures  are  created  with  both  compliance  and  practicality  in 

mind.  The  compliance  aspect,  driven  by  law  and  policy,  is  represented  within  this 

chapter  of  research.  The  practical  aspect  is  characterized  through  experience  which: 

has  demonstrated  that  the  management  of  large  organizations  employing 
sophisticated  systems  and  technologies  in  pursuit  of  joint  missions  demands  a 
structured,  repeatable  method  for  evaluating  investments  and  investment 
alternatives,  as  well  as  the  ability  to  effectively  implement  organizational  change, 
create  new  systems  and  deploy  new  technologies  (DoD  2007). 

Mindful  of  both  aspects,  the  DoD  Architecture  Framework  (DoDAF)  was  created  as  a 

guide  towards  the  development  of  architectures.  DoDAF  serves  as  “the  guidance  and 

rules  for  developing,  representing,  and  understanding  architectures  based  on  a  common 

denominator  across  DoD,  Joint,  and  multinational  boundaries,”  (DoD  2007).  The  guide 
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achieves  a  baseline  across  these  boundaries  by  acting  as  a  descriptive  catalog  of  possible 
architectural  models  whose  contents  provide  consistency  “across  all  mission  operations 
and  processes,  and  enabling  the  integration  and/or  federation  of  architecture  in  support  of 
joint  capabilities,”  (DoD  2007).  DoDAF  approaches  architecting  from  a  data-centric 
perspective  allowing  the  framework  to  accommodate  the  recent  net-centric  focus  of  the 
GIG.  Within  this  perspective,  a  value-added  distinction  is  made  between  integrated  and 
federated  architectures.  An  integrated  architecture  refers  to  a  consistent  identification  of 
data  elements  amongst  all  of  its  represented  products  and  views  which  provides  a 
“broader  perspective  of  the  mission  by  representing  data  elements  through  multiple 
views,”  (DoD  2007).  Federated  architectures  align  dissimilar  “architectures  and 
architecture  information  via  infonnation  exchange  standards... providing  a  holistic 
enterprise  view  that  allows  for  the  assessment  of  interoperability,  identification  of 
duplication  and  gaps,  or  detennination  of  reusability,”  (DoD  2007). 

DoDAF,  the  framework  in  use  by  the  DoD,  consists  of  a  data  and  presentation 
layer,  illustrated  in  Figure  7.  The  data  layer  contains  the  defining  attributes  and 
relationships  of  the  architecture’s  data  elements  and  the  presentation  layer  reflects  “the 
products  and  views  that  support  a  visual  means  to  communicate  and  understand  the 
purpose  of  the  architecture,  what  it  describes,  and  the  various  architectural  analyses 
performed,”  (DoD  2007).  The  products  of  the  presentation  layer  provide  “a  way  for 
visualizing  architecture  data  as  graphical,  tabular,  or  textual  representations,”  whereas  the 
views  “provide  the  ability  to  visualize  architecture  data  that  stem  across  products, 
logically  organizing  the  data  for  a  specific  or  holistic  perspective  of  the  architecture,” 
(DoD  2007).  Volume  I  of  DoDAF  is  dedicated  to  the  definition  of  those  views  and 
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includes  descriptions  of  architecture  development,  usage,  and  management.  Volume  II 
provides  descriptions  of  each  of  the  data  and  product  types.  Volume  III  describes  the 
aspects  that  comprise  the  architecture  data  management  strategy  (DoD  2007). 


Presentation  Layer 


Products  Views 


Data  Layer 

Architecture  Data  Elements 


Figure  7:  DoDAF  Structure  (DoD  2007) 


AF Level EA  Guidance 

To  assist  the  management  complexity  of  information  and  the  complex 
relationships  amongst  its  processes,  the  Air  Force  establishes  the  requirement  for  EA  use 
in  AF  Policy  Directive  33-4,  Enterprise  Architecting.  The  guidance  directs  the  AF  to  use 
EA  as  “a  decision-support  tool  to  inform,  guide,  and  support  the  decisions  of  the  Air 
Force  enterprise.”  Within  this  context,  the  AF  EA  consists  of  a  federation  of 
architectures,  or  collection  of  sub-enterprise  architectures,  whose  capabilities  are  used  to 
“analyze  problems,  answer  questions,  guide  future  actions,  and  unify  capabilities  that  cut 
across  functional  areas  to  create  desired  effects,”  (DAF  2006).  Explicitly  the  AF  EA: 


28 


describes  relationships  among  key  Air  Force  institutional  processes  to  ensure:  (1) 
Alignment  of  information  systems  requirements  with  the  processes  that  support 
Air  Force  missions;  (2)  Adequate  Air  Force,  joint,  and  allied  and  coalition 
interoperability;  (3)  Redundancy  and  security  of  information  systems;  and  (4)  The 
application  and  maintenance  of  a  set  of  standards  by  which  the  Air  Force 
evaluates  and  acquires  new  systems  (DAF  2006). 

AFPD  33-4  requires  all  AF  organizations  to  employ  enterprise  architecting  and  requires 
those  architectures  to  align  with  the  Air  Force  Enterprise  Architecture  and  its  sub¬ 
enterprises  architectures  as  well  as  comply  with  architectural  instructions  found  in  upper 
level  guidance.  To  enable  the  integration  and  reuse  of  architectural  artifacts,  AFPD  33-4 
calls  for  the  use  of  common  architectural  tools  and  methodologies  as  well  as  an 
architecture  repository  to  house  all  certified  and  approved  architectures.  Major  AF 
Commands  (MAJCOMs)  provide  the  oversight  of  program  and  lower  level  architecture 
activities  by  establishing  policies,  procedures,  and  guidelines  to  ensure  architectures  are 
inclusive  and  consistent  with  the  AF  EA  (DAF  2006). 

Implementing  the  requirements  of  AFPD  33-4,  Air  Force  Instruction  (AFI)  33- 
401,  Implementing  Air  Force  Architectures,  describes  the  Air  Force  Enterprise 
Architecture  and  assigns  responsibility  for  its  federated  architectures.  AFI  33-401 
describes  the  AF  Enterprise  Architecture  as  utilizing  a  federated  approach,  which  consists 
of  “nested”  architectures.  Representing  the  lowest  level  is  program  architectures,  which 
are  a  part  of,  and  conform  to  MAJCOM  architectures.  MAJCOM  architectures  then 
federate  with  other  sub-architectures  to  create  the  AF  EA,  which  also  “nests”  into  the 
larger  DoD  and  Federal  Enterprise  Architectures,  as  depicted  in  Figure  1.  The  purpose  of 
this  approach  prevents  duplication  and  ensures  the  development  of  architectures  support 
decision-makers  at  all  levels  (DAF  2007).  In  addition  to  establishing  architecting  roles 
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and  responsibilities  for  the  Air  Force,  AFI  33-401  also  implements  a  governing  set  of 
processes,  “structured  to  oversee  the  development,  alignment,  certification,  maintenance, 
and  application  of  the  AF  EA  and  subordinate  architectures,”  (DAF  2007). 
Accommodating  the  architecture  certification  and  approval  requirements  found  in  CJCSI 
62 12.0 ID  and  DoDD  4630.5,  AFI  33-401  provides  avenues  that  “provide  for  the  quality 
control  and  configuration  management  of  the  architecture,  alignment  with  appropriate 
higher-level  and  ‘peer’  architectures,  and  the  accuracy  and  applicability  of  user 
activities,”  (DAF  2007).  The  AFI  also  directs  the  creation  of  the  Air  Force  Architecture 
Repository  System  to  serve  as  the  authoritative  source  for  AF  architecture  artifacts. 

Leveraging  aspects  of  DoDAF  and  the  FEA  reference  models  found  in  the  Federal 
Enterprise  Architecture  Framework,  AFI  33-401  establishes  the  AF  EA  Framework  (AF 
EAF)  to  provide  “the  logical  structure  for  classifying,  organizing,  and  relating  the  breadth 
and  depth  of  information  that  describes  and  documents  the  AF  EA,”  (DAF  2007).  The 
AF  EAF  consists  of  the  architectural  aspects  that  contribute  to  the  creation  and 
integration  of  AF  architectures  and  suffices  the  EA  requirements  set  forth  by  OMB 
Circular  A- 130.  The  AF  EAF,  illustrated  in  Figure  8,  consists  of  three  parts.  Conjoined 
they  embody  guidance  drivers  and  inputs,  the  description  layers  or  perspectives  that 
relate  to  a  “full-spectrum”  of  architecture  products  and  artifacts,  and  the  uses  and  impact 
of  the  AF  EAF  (AF  CIO  2003). 
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Figure  8:  AF  EAF  Overview  (AFI  CIO  2003) 


EA  Guidance  Analysis 

The  topic  of  EA  has  been  well  thought  out  by  the  governing  bodies  of  the  Federal 
Government  as  represented  by  the  large  sample  of  EA  guidance  contained  in  the 
summary.  However,  despite  these  efforts,  overall  EA  effectiveness  ranks  low  and  does 
not  support  informed  IT  decision-making,  and  the  true  achievement  of  alignment  remains 
doubtful  (US  GAO  2002;  US  GAO  2008;  Plazaola  et  al.  2007).  These  issues  prompt  the 
question,  “Does  the  guidance  contrive  to  the  effective  use  of  EA  and  attribute  to  the 
achievement  of  alignment?”  The  remainder  of  this  chapter  consists  of  an  AF-level 
guidance  analysis  on  the  inclusion  of  the  EA  best  practices  identified  by  the  literature 
search  of  this  research. 
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Vision 


Generally,  the  guidance  contained  in  the  summary  spelled  out  those  responsible 
for  ensuring  a  sound  and  integrated  architecture,  defined  its  boundaries,  and  established 
constructs  to  manage  it  (US  Congress  1996;  DoD  2002b;  DoD  2004).  In  review,  an  EA 
vision  defines  how  the  enterprise  will  use  IT  in  support  of  strategy.  This  topic  was 
pervasive  and  clear  throughout  the  Air  Force  (and  higher)  guidance,  as  can  be  seen  in  the 
FEA  vision  to: 

develop,  maintain,  and  facilitate  the  implementation  of  the  top-level  enterprise 
architecture  for  the  Federal  Enterprise.  This  architecture  will  serve  as  a 
reference  point  to  facilitate  the  efficient  and  effective  coordination  of  common 
business  processes,  information  flows,  systems,  and  investments  among  Federal 
Agencies.  In  time,  Government  business  processes  and  systems  will  operate 
seamlessly  in  an  enterprise  architecture  that  provides  models  and  standards  that 
identify  and  define  the  information  services  used  throughout  the  Government 
(CIO  Council  1999). 

Collectively,  the  analysis  discovered  the  AF  EA  vision  establishes  the  purpose  for  the 
architecture’s  existence.  It  calls  for  the  EA  to  inform,  guide,  and  support  key  decision¬ 
making  processes  through  means  that  detennine  interoperability  and  capability  needs. 
Specifically  in  strongly  networked  environments,  many  of  the  distributed,  programmatic 
decisions  involve  allowing  information  to  be  “visible,  accessible,  and  understandable  to 
any  authorized  user,”  (DoD  2007;  DAF  2006;  DoD  2004).  The  architecture  does  this  by 
acting  as  a  living  representation  of  the  enterprise,  reflecting  how  the  mission  is 
perfonned,  how  the  information  is  consumed  and  produced,  and  how  its  enabling 
technologies  are  implemented,  effectively  attributing  to  the  Air  Force’s  ability  to  achieve 
information  superiority  (DoD  2007;  DAF  2007). 
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Referring  back  to  the  operating  models,  illustrated  in  Table  1,  this  analysis 
identifies  the  AF  as  utilizing  the  Coordination  operating  model  to  drive  its  IT  strategy. 
Although  the  operating  model  is  not  actively  identified  and  pursued,  the  AF’s  nature  to 
use  IT  to  achieve  high  levels  of  integration  where  customers,  products,  suppliers,  and 
partners  are  shared  and  whose  business  units  have  unique  operations  and  capabilities 
places  it  within  this  category.  With  the  ability  to  succeed  being  supported  by  matching  a 
defined  operating  model  to  growth,  the  AF  could  benefit  by  structuring  the  strategy  of  its 
potential  IT  growth  after  an  operating  model  that  not  only  focuses  on  integration,  but 
process  standardization  as  well.  A  strategy  built  on  both  components  allows 
organizations  to  leverage  IT  into  a  more  proactive  manner  (Ross  et  al.  2006). 

Identification 

Through  EA  identification,  an  organization  captures  a  description  of  their  IT 
architecture  and  processes  allowing  them  to  conjure  an  assessment  of  how  well  IT  is 
assisting  processes  in  the  accomplishment  of  the  mission  and  develop  a  roadmap  to  drive 
future  IT  efforts.  The  guidance  analysis  discovered  that  reengineered  business  processes 
are  a  forceful  factor  behind  ensuring  IT  is  applied  effectively  within  the  AF.  In 
conjunction  with  ensuring  AF  processes  are  efficient,  the  described  EA  efforts  found 
within  the  guidance  stipulates  that  the  IT  applied  to  those  processes  are  interoperable, 
integrated,  and  federated.  The  given  benefits  of  these  actions  allow  architectures  to  be 
identified  within  a  similar  plane  of  existence.  Utilizing  the  assessment  of  the  four  stages 
of  architecture  maturity  described  in  the  identification  best  practice  of  Chapter  II,  this 
state  of  an  architecutre  represents  a  Business  Silo  maturity  where  data  and  performance  is 
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locally  maximized  and  the  architecture  does  not  constrain  IT  implementation  (DAF  2007; 
Ross  et  al.  2006). 

This  level  of  maturity  involves  implementations  driven  by  the  design  of  a  process 
where  IT  is  then  developed  or  purchased  to  fulfill  the  functionality  of  that  process. 
Benefits  of  this  stage  of  architecture  maturity  include  a  100  percent  solution  provided  to 
the  business  need  and  a  naturally  aligned  IT  and  business  unit.  The  disadvantage  of  this 
stage  of  maturity  is  that  it  results  in  the  creation  of  legacy  systems  that  cannot 
communicate  with  each  other  without  the  costly  intervention  of  software  programmers, 
hindering  process  integration  and  standardization.  The  primary  reason  to  progress  past 
this  maturity  stage  is  the  large  cost  inherent  with  legacy  systems.  Organizations 
warranting  IT  efficiency  and  a  solid  data  and  process  platform  seek  to  move  to  the 
Standardized  Technology  stage  of  architecture  maturity.  Within  this  stage,  the  role  of  IT 
remains  the  same,  which  is  to  automate  local  processes,  however,  the  emphasis  on  the 
management  of  IT  changes  from  ensuring  functionality  towards  providing  cost- 
effectiveness  and  reliability  (Ross  et  al.  2006). 

Recent  Air  Force  IT  initiatives  such  as  server  consolidation,  E-mail  for  Life,  and 
the  Standard  Desktop  Configuration  reflect  attributes  from  the  Standardized  Technology 
architecture  maturity  phase,  such  as  IT  efficiencies  being  provided  through 
standardization,  an  emphasized  IT  management,  and  increased  centralization  and  access 
to  shared  data.  However,  the  question  remains  if  these  programs  are  driven  by  the 
architecture  or  are  representative  of  other  dealings.  A  search  of  AF  IT  initiative 
documentation  concluded  that  these  initiatives  were  not  contrived  from  the  guidance. 
Although  the  inherited  use  of  EA  captures  the  “as  is”  state  of  an  architecture,  an 


34 


additional  enterprise-wide  IT  architecture  identification  could  be  beneficial  to  propel 
strategic  capabilities. 

Framework 

Through  a  chosen  EA  framework,  a  consistent  representation  of  the  relationships 
of  an  organization’s  resources  is  shared,  collectively  describing  mission  accomplishment 
despite  the  inherent  multiple  views  or  perspectives.  The  guidance  analysis  identified 
three  frameworks  having  prescriptive  effects  on  Air  Force  programs  today.  They  consist 
of  the  Federal  Enterprise  Architecture  Framework,  the  DoD  Architecture  Framework,  and 
the  AF  Enterprise  Architecture  Framework.  The  most  prominent  level  of  guidance 
directing  Air  Force  enterprises,  the  AF  EAF,  leverages  aspects  from  both  the  FEAF  and 
DoDAF  in  support  of  the  AF’s  “vision,  mission,  transformational  objectives,  and 
operational  concepts,”  (AF  CIO  2003).  Specifically  it  “provides  the  logical  structure  for 
classifying,  organizing,  and  relating  the  breadth  and  depth  of  infonnation  that  describes 
and  documents  the  Air  Force  Enterprise  Architecture,”  (AF  CIO  2003).  Focusing 
directly  on  a  framework’s  purpose,  the  AF  EAF  supports: 

•  Alignment  of  requirements  for  infonnation  systems  with  the  processes  that 
support  the  AF  missions 

•  Adequate  AF,  Joint,  and  combined  interoperability 

•  Integration,  assurance,  and  security  of  information  systems 

•  Prioritized  allocation  of  resources  to  critical  capabilities 

•  The  application  and  maintenance  of  a  set  of  standards  by  which  the  AF  evaluates 
and  acquires  new  systems  (AF  CIO  2003) 
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Governance 


As  stated  earlier,  effective  governance  relates  to  the  management  and  use  of  IT 
within  an  organization.  Inherent  to  this  definition  and  a  factor  documented  by  the  GAO 
to  be  the  most  lacking  within  the  DoD,  is  an  attitude  influencing  EA  to  extract  desirable 
behaviors  from  IT  (US  GAO  2008).  Throughout  the  referenced  guidance,  the  designation 
of  “governance”  was  commonly  used  to  refer  to  the  oversight  of  EA  use  as  well  as  to 
describe  its  apparent  benefits.  However,  absent  from  this  depiction  of  “governance”  is  an 
EA  endorsing  environment  consisting  of  allocated  resources,  management  importance,  or 
the  need  for  culture  change.  Best  practices  describe  governance  structures  to  consist  of 
IT  investment  management  processes,  communication  strategies,  ownership,  and 
accountability.  However,  this  aspect  of  aligmnent  appears  most  lacking  amongst  the 
guidance  (US  GAO  2008).  For  the  military,  an  attitude  supporting  governance  needs  to 
be  fueled  with  commander’s  intent  to  facilitate  the  alignment  of  IT  with  mission,  not  with 
just  words  of  guidance,  but  with  action. 
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Summary 

This  chapter  identified  and  described  the  different  guidance  within  the  AF 
contributing  to  the  prescription  and  description  of  EA  use.  Considering  the  low 
effectiveness  of  EA  throughout  the  Federal  Government,  a  review  and  assessment  was 
perfonned  on  the  guidance’s  inclusion  of  aspects  attributing  to  EA  aligmnent  (CIS  GAO 
2002;  US  GAO  2008).  The  search  revealed  that  the  Air  Force’s  IT  is  not  driven  by  its 
EA.  An  identified  operating  model  could  be  used  to  drive  the  application  of  IT  towards 
the  AF’s  vision  and  allow  for  an  assessment  of  those  assets  as  they  apply  towards  that 
vision  and  mission  accomplishment.  The  analysis  also  found  attitude,  a  factor  of  the 
governance  best  practice,  to  be  missing  from  the  guidance.  The  attitude  needed  is  one 
that  would  encourage  action  and  affect  decision-making  on  all  levels  in  order  to  facilitate 
the  EA  vision. 
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IV.  Analysis  of  Alignment 


Overview 

An  effective  EA  reflects  the  essence  of  alignment  by  facilitating  the  application  of 
IT  in  accord  to  an  organization’s  strategies,  goals,  and  needs  (Luftman  2004).  The 
benefit  of  such  facilitation  increases  integration  and  decreases  the  duplication  of 
processes  and  systems,  optimizing  mission  performance.  These  resounding  results  echo 
throughout  the  enterprise  affecting  continued  and  new  implementations  of  IT  (US  GAO 
2002).  The  validity  of  this  concept  is  apparent  when  observed  from  the  context  of  an  IT 
project. 

In  this  chapter,  a  case  study  is  presented  representing  the  depiction  of  a  typical, 
large-scale  deployment  of  an  enterprise  software  application.  The  case  study  gauges  the 
applicability  of  the  four  EA  best  practices  vision,  identification,  framework,  and 
governance  towards  a  real-world  example  with  the  expectation  to  represent  their  merit 
towards  alignment.  The  infonnation  describing  the  representative  IT  project  portrayed  in 
this  case  study  was  derived  from  the  Chief  Information  Office  (CIO)  Support  Branch  and 
Knowledge  Operations  section  of  Headquarters  (HQ)  United  States  Air  Forces  in  Europe 
(USAFE),  Ramstein  Air  Base,  Gennany. 

Project  Background 

This  particular  IT  project  began  as  a  requirement  originating  from  USAFE’s  HQ 
Office  of  the  Director  of  Staff  (DS).  Details  of  the  requirement  consisted  of  solving  the 
task  management  problems  experienced  throughout  USAFE  by  selecting  a  solution  that 
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has  the  capability  to  serve  as  an  enterprise-wide  task  management  standard.  Current  task 
management  practices  consist  of  arbitrary  processes  that  span  across  the  command.  Their 
deficiencies  do  not  provide  for  status  visibility  or  collaborative  opportunities  and 
adversely  affect  the  storage  and  rapid  discovery  of  infonnation.  Further  advocating  the 
need  for  a  new  tool,  the  current  processes  and  tools  do  not  contain  the  scalability  needed 
to  serve  as  an  enterprise- wide  task  management  standard.  The  team  constructed  to  solve 
this  issue  consisted  of  individuals  originating  from  USAFE  DS,  HQ  USAFE  Directorates, 
and  Microsoft  Process  experts  (Belue  2008). 

Capturing  the  Process 

USAFE  exercises  a  strategic  plan  that  includes  the  presence  and  infrastructure  to 
enable  access  throughout  their  area  of  responsibility.  Access,  in  this  case,  refers  to  such 
things  as  the  access  used  to  enable  mission  accomplishment  and  the  access  that  enhances 
the  interoperability  with  partners  and  allies.  Access  is  paramount  to  USAFE’s  ability  to 
project  power.  This  depiction  of  presence  and  infrastructure  can  be  transposed  onto 
many  USAFE  assets,  including  their  utilization  of  IT.  USAFE  consists  of  roughly  35,000 
users  spread  out  amongst  16  different  installations  (Belue  2008).  Their  ability  to  execute 
their  strategic  plan  provides  the  interoperability  of  these  sites. 

USAFE  supports  downward  directed  Air  Force  Smart  Operations  21  (AFSO-21) 
initiatives.  The  program  management  team  assigned  to  solve  the  task  management 
dilemma  began  by  collecting  detailed  information  regarding  the  task  management 
problem  as  well  as  details  of  the  required  solution.  This  was  accomplished  through  the 
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initiation  of  an  AFSO-21  influenced  Lean  Six  Sigma  analysis  on  the  current  USAFE  task 
management  process.  The  analysis  concluded: 

•  Subject  matter  experts  (SME)  indicated  that  less  than  3 1%  of  the  current  task 
management  processes  are  effective 

•  SMEs  indicated  that  current  technology  support  meets  the  task  management 
process  needs  less  than  47%  of  the  time 

•  SMEs  indicated  that  less  than  59%  of  the  current  task  management  processes 
are  effective  (Conway  2006) 

Concurrent  with  the  Lean  Six  Sigma  analysis,  the  team  initiated  a  pilot  study  to 
collect  data  from  interviewed  functional  and  operational  leaders  from  around  USAFE. 

The  results  of  interviews  conducted  as  part  of  this  pilot  study  allowed  for  the  creation  of  a 
ranked  list  of  goals  to  which  the  new  solution  must  adhere.  The  captured  goals  require 
the  tool  to  accommodate: 

1 .  Collaborating  with  others 

2.  Content  related  data  transfer,  sharing  and  tracking  among  different  functional 
areas  at  the  appropriate  security  levels 

3.  Finding  and  retrieving  infonnation 

4.  Communicating  required  information  for  approvals  (Conway  2006) 
Collectively,  the  infonnation  from  their  analyses  provided  the  program 

management  team  with  the  insight  to  rank  visibility  and  efficiency  as  the  key  elements 
needed  to  improve  the  current  task  management  process.  Structured  around  this 
realization,  the  team  developed  a  way-ahead  solution  calling  for  a  dynamic,  commercial 
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off-the-shelf  tool  that  can  be  easily  integrated  with  the  enterprise  architecture  and 
applications  currently  in  place  (Belue  2009). 


Integrating  with  Existing  IT 

Driven  by  their  strategic  plan,  USAFE’s  IT  infrastructure  supplies  sufficient 
connectivity  to  provide  the  interoperability  with  multiple  installations  and  is  supportive 
of  an  enterprise-wide  solution.  The  program  management  team  utilizes  existing 
architectural  diagrams,  shown  in  Figure  9,  to  identify  and  assess  the  capabilities  of 
USAFE’s  enterprise  services  and  applications.  The  information  provided  by  drawings 
such  as  these  provide  the  team  with  the  interfaces,  architecture,  and  infrastructure  the 
new  solution  must  integrate  with  in  order  to  adhere  to  the  business  scenarios  created  from 
the  ranked  list  of  requirements  (Conway  2006). 
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Figure  9:  USAFE  Enterprise  Services  (Conway  2006) 
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Other  information  made  available  to  the  team  consisted  of  diagrams  depicting  the 


players  and  flow  of  information  surrounding  the  current  USAFE  task  management 
process,  illustrated  in  Figure  10.  The  information  obtained  from  these  architectural 
artifacts  identifies  the  flow  of  a  task  as  it  progresses  from  the  office  of  the  USAFE 


Director  of  Staff  (DS)  throughout  the  rest  of  the  command  (Belue  2009). 


The  program  management  team  also  initiates  an  audit  capturing  the  specific 
activities  different  types  of  enterprise  users  engage  in  throughout  a  given  workday.  The 
audit  consists  of  capturing  the  percentage  of  time  each  type  of  user  performs  tasks 
associated  with  the  goals  driving  the  new  solution.  The  result  of  the  audit,  illustrated  in 
Figure  11,  is  useful  towards  identifying  gaps  and  provides  a  starting  point  for 
investigating  how  information  supports  worker  enablement  (Conway  2006). 
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Capturing  Project  Requirements 

The  information  collected  up  to  this  point  allows  the  program  management  team 
to  separate  the  USAFE  task  management  process  into  three  procedures  or  work  scenarios. 
The  new  solution  must  account  for  all  three  procedures  to  capture  every  facet  of  the  task 
management  process.  The  first,  consisting  of  administrative  task  management,  surrounds 
the  procedures  accomplished  by  USAFE  DS  in  regards  to  task  initiation,  timeline 
determination,  selection  of  the  Office  of  Primary  Responsibility  (OPR),  and  tracking  of 
the  task  until  completion.  The  second  task  management  procedure,  operational  task 
management,  consists  of  tasks  such  as  receiving  the  task  from  USAFE  DS,  establishing  a 
task  definition,  and  selecting  the  organization  that  will  work  the  task  and  create  the 
deliverable.  The  third  task  management  procedure  is  a  Request  for  Information  (RFI) 
based  work  process.  This  procedure  involves  providing  answers  to  time-sensitive  ad  hoc 
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or  routine  requirements  as  well  as  directing  the  production  of  intelligence  information  or 
products  (Belue  2009). 

The  project  management  team  captures  each  of  these  work  scenarios  into  a 
workflow  diagram  to  relate  the  players,  information,  and  the  tasks  involved.  As  can  be 
seen  in  the  illustrated  operational  task  management  procedure  of  Figure  12,  these  process 
diagrams  allow  the  program  management  team  to  identify  parts  of  task  management  that 
create  lost  value  or  wasted  effort,  ensuring  these  issues  are  avoided  in  the  new  solution 
(Belue  2009). 


Figure  12:  Operational  Task  Management  Procedure  (Conway  2006) 
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Implementing  the  Solution 

The  requirement  to  solve  the  task  management  issue  is  well  known  throughout 
USAFE.  The  program  management  team  experienced  the  necessary  organizational 
freedom  to  collect  the  analysis  data  needed  to  improve  the  process  and  acquire  a  suitable 
solution.  As  a  result,  the  selected  resolve  consists  of  a  multiple  layered  enterprise-wide 
solution  of  capabilities  derived  from  incorporating  the  already  implemented  AF  standard 
Enterprise  Infonnation  Management  (EIM)  solution  as  well  as  new  features  obtained 
from  Microsoft’s  Customer  Relations  Management  (CRM)  software  solution  (Belue 
2009). 

The  AF  EIM  solution  consists  of  a  Microsoft  SharePoint  suite,  which  provides  the 
foundation  for  document  sharing  and  collaboration  throughout  USAFE,  as  well  as  a  SQL 
database  providing  management  of  all  data.  The  Microsoft  CRM  tool  provides  the 
capability  to  project  enterprise-wide  visibility  of  cross-functional  mission  efforts. 
Collectively,  the  system  of  systems  encompassing  the  entire  solution  is  the  USAFE  Task 
Management  Tool  (TMT)  (Belue  2009). 

The  TMT  solution,  illustrated  in  Figure  13,  provides  the  capability  that  begins 
with  the  initiation  of  a  task  that  has  to  be  coordinated  through  the  Staff  or  Wings  within 
USAFE.  Someone,  normally  the  DS  or  Executive  Officer  initiates  the  task  by  clicking  on 
the  CRS  provided  button  within  Microsoft  Outlook  to  create  the  core  pieces  of  the  task 
and  load  the  applicable  attachments  into  the  repository  of  the  EIM.  The  task  is  then 
routed  to  an  OPR  and  one  or  many  Office(s)  of  Collateral  Responsibility  (OCR)  that  can 
then  assign  it  to  Action  Officers  (AO)  for  action.  Upon  completion,  the  task  is  staffed 
back  up  the  chain  for  approval  and  eventually  released  by  the  generating  Authority. 
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TMT  as  a  whole  provides  the  capability  of  tracking  task  progression  via  real-time 
visibility  of  assigned  or  open  tasks  anywhere  throughout  USAFE  (Belue  2009). 


Figure  13:  USAFE  Task  Management  Solution  based  on  Microsoft  CRM  and  AF  EIM 

solution  (Belue  2009) 


Implementation  of  the  TMT  solution  was  consistent  of  an  iterative  development 
process,  which  creates  and  tests  sequential  builds  repeatedly,  until  it  sustains  stability 
standards.  As  a  result,  TMT  data  is  captured  centrally  into  a  repository  where  data 
queries  can  be  tailored,  streamlining  task  reporting  at  multiple  levels  throughout  the 
command.  Along  with  the  task  management  advancements  the  tool  provides,  other 
processes  throughout  the  enterprise,  such  as  communications  requirements,  training, 
metrics  gathering,  and  trouble  ticket  management,  can  leverage  the  now  in  place  CRM 
capabilities  to  reengineer  their  processes.  A  replication  of  these  process  improvements 
could  be  benchmarked  and  incorporated  Air  Force-wide  (Belue  2009). 
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The  TMT  solution  did  come  at  a  cost.  In  addition  to  the  initial  start-up  cost, 
annual  operation  and  maintenance  costs  are  also  incurred.  Justification  of  the  cost  is  that 
the  TMT  solution  will  provide  USAFE: 

•  A  savings  of  over  18,000  man-hours  a  year 

•  Collaborative  benefits  that  reduces  rework  at  all  levels  of  the  command 

•  100  percent  tasker  visibility  throughout  the  command 

•  Reduction  of  data  storage  by  more  than  60  percent  (Belue  2009) 

Through  cost  avoidance  and  the  benefits  just  described,  USAFE  plans  to  receive  a  return 
on  their  investment  in  just  three  years  (Belue  2009). 

Project  Retrospective 

The  EA  best  practices,  vision,  identification,  framework,  and  governance,  can 
become  apparent  within  project  execution  when  the  enterprise  within  which  they  operate 
consists  of  IT  that  is  aligned  with  the  mission  as  well  as  a  mission  that  is  aligned  with  IT 
(Luftman  2007).  The  task  management  project  is  representative  of  this  fact.  The  project 
operates  within  an  environment  that  utilizes  an  infonnation  production  line  that  delivers 
tangible  results  that  drive  the  business.  Technology  is  used  to  create,  modify,  and  utilize 
infonnation  that  in  turn  creates  products  or  services  for  their  customers.  The  value  of  this 
infonnation  work  is  a  product  of  the  cost  of  worker  enablement.  This  enablement 
process  entails  ensuring  the  right  processes  are  in  place,  the  right  procedures  are  known, 
and  the  right  technologies  are  used.  The  four  EA  best  practices  can  provide  prospective 
and  retrospective  effects.  As  the  project  is  planned  and  implemented,  they  guide  the 
project  to  ensure  it  is  aligned  with  the  enterprise.  After  the  project  is  implemented,  the 
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best  practices  can  serve  as  an  assessment  tool,  evaluating  the  project’s  ability  to  align 
itself  within  the  enterprise.  The  descriptive  details  of  the  task  management  project 
demonstrate  this  ability. 

When  reviewing  the  task  management  project,  USAFE  did  not  utilize  an 
operating  model  to  define  a  definitive  vision.  However,  components  of  their  strategic 
plan  facilitated  the  task  management  solution  to  create  a  cross-utilization  of  process 
integration  and  process  standardization,  reminiscent  of  the  Unification  Operating  Model 
described  within  the  vision  best  practice  of  Chapter  II.  The  characteristics  of  this 
operating  model,  listed  below  and  illustrated  in  Table  1,  coincide  with  the  capabilities  of 
the  TMT  solution: 

•  Globally  integrated  business  process  with  the  support  of  enterprise  systems 

•  Business  units  with  similar  or  overlapping  operations 

•  Centralized  management  often  applying  functional,  process,  and  business  unit 
matrices 

•  High-level  process  owners  who  design  standardized  processes 

•  Centrally  managed  databases 

•  IT  decision  are  made  centrally  (Ross  et  al.  2006) 

USAFE  also  accounts  for  components  of  the  AF-wide  vision  within  its  decision¬ 
making  processes.  Suggestive  of  this  fact  is  the  MAJCOM’s  acquiescence  with  Air 
Force  AFSO-21  initiatives  and  USAFE’s  ability  to  create  parallelism  between  the  task 
management  requirement  of  worker  enablement  and  AF  EA  usage.  Worker  enablement, 
which  again  consists  of  ensuring  the  right  processes  are  in  place,  the  right  procedures  are 
known,  and  the  right  technologies  are  used,  coincides  with  the  AF  EA  consisting  of 
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reflecting  how  the  mission  is  performed,  how  the  infonnation  is  consumed  and  produced, 
and  how  its  enabling  technologies  are  implemented  (DAF  2007). 

During  the  analysis  of  the  captured  information,  the  project  management  team 
identified  the  current  task  management  process  as  well  as  the  current  capabilities  of 
USAFE’s  IT.  Figures  9,  10,  and  1 1  are  representative  of  this  statement.  Although  an 
actual  architecture  maturity  assessment  was  not  conducted  on  the  USAFE  EA,  the 
captured  hardware,  software,  and  infrastructure  represented  in  these  architectural  artifacts 
shows  that  the  task  management  process  favors  the  Optimized  Core  architecture 
described  in  the  identification  best  practice  of  Chapter  II.  This  type  of  architecture 
supports  organizational  wide  data  and  process  standardization  (Ross  et  al.  2006). 
Retrospectively,  the  architecture  surrounding  the  task  management  process  consists  of  the 
sufficient  connectivity  and  suite  of  enterprise  services  to  support  the  operation  and 
maintenance  of  the  TMT  solution. 

The  methods  used  to  construct  the  diagrams  found  in  Figures  9  through  13  do  not 
necessarily  coincide  with  the  definition  of  products  found  within  DoDAF  or  the  AF  EAF. 
However,  they  do  reflect  framework  views.  The  USAFE  diagrams  reflect  the  art  of  EA 
discussed  within  the  framework  best  practice  of  Chapter  II.  Through  the  experience, 
insight,  and  common  sense  of  the  program  management  team  a  subtle  framework  was 
established  that  ensured  the  analyses  of  the  previous  task  management  process  effectively 
captured  key  customers,  linked  and  standard  processes,  shared  data,  and  linked 
automating  technologies  (Ross  et  al.  2006).  The  value  of  these  diagrams  lies  within  their 
ability  to  capture  the  relationships  and  information  surrounding  the  task  management 
process. 
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As  stated  earlier,  the  TMT  solution  solved  an  issue  that  was  shared  by  many  and 
well  known  throughout  USAFE.  As  a  result,  the  project  experienced  appropriate 
organizational  freedom  to  collect  the  necessary  data,  which  resulted  with  a  solution  that 
aligned  the  goals  of  the  solution  with  the  objectives  stated  in  USAFE ’s  strategic  plan. 
These  important  factors  of  governance  resulted  in  a  solution  that  not  only  solved  the  task 
management  problem,  they  also  put  into  place  the  technology  that  other  USAFE 
processes  can  leverage  to  bring  forth  more  capabilities  and  a  greater  return  on  investment. 
The  ability  of  TMT  to  align  with  the  needs  of  the  task  management  process,  and  other 
similar  processes  being  able  to  align  with  TMT,  portrays  the  very  nature  of  alignment. 

Summary 

The  resounding  results  of  alignment  echo  throughout  the  enterprise  affecting 
continued  and  new  implementations  of  IT.  The  validity  of  this  concept  is  apparent  when 
observed  from  the  context  of  an  IT  project.  This  chapter  presented  a  typical,  large-scale 
deployment  of  an  enterprise  software  application  shown  to  exhibit  aspects  of  the  EA  best 
practices,  vision,  identification,  framework,  and  governance.  The  portrayal  of  alignment 
represented  within  this  chapter  complements  the  descriptive  trend  of  this  research  by 
presenting  the  applicable  nature  of  these  best  practices  and  creating  a  self-actualization  of 
alignment’s  inherent  benefits. 


50 


V.  Conclusions  and  Recommendations 


This  chapter  presents  conclusions  attained  as  a  result  of  this  work  and  then 
addresses  suggestions  for  future  research. 

Conclusions 

This  research  uncovers  areas  of  best  practices  that  support  achieving  alignment 
between  an  organization’s  IT  and  its  business  processes.  One  principal  finding  of  this 
effort  revealed  that  the  best  practices  contributing  to  alignment  exist  as  characteristics  of 
Enterprise  Architecture  (EA),  a  common  practice  found  throughout  the  Federal 
Government,  Department  of  Defense,  and  the  Air  Force.  EA  is  the  tool  used  to  achieve 
alignment;  likewise,  the  reason  for  developing  architecture  is  to  achieve  alignment  of  IT 
investment  and  mission  objectives. 

Information  Technology  has  become  an  integral  part  of  mission  accomplishment 
and  a  factor  the  United  States  military  continually  strives  to  use  strategically.  The  logic 
of  EA,  with  its  goal  of  aligning  an  organization’s  IT  and  systems  with  its  processes, 
provides  a  map  to  the  executable  nature  of  alignment.  This  research  serves  as  a  guideline 
towards  alignment.  Its  application  should  strengthen  the  use  of  Enterprise  Architecture 
within  the  Air  Force  by  enabling  senior  leaders  and  decision  makers  to  align  strategy  and 
IT  investment  towards  improving  mission  accomplishment. 

This  research  accomplishes  this  endeavor  by  answering  the  following  research 
questions  surrounding  the  concept  of  EA  alignment. 

1 .  What  Enterprise  Architecture  best  practices  attribute  to  the  successful 

achievement  of  alignment? 
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With  the  realization  of  Enterprise  Architecture’s  ability  to  contribute  to  the 
achievement  of  aligmnent,  this  research  began  with  the  literature  review  of  Chapter  II. 
The  goal  of  the  review  was  to  search  the  EA  body  of  knowledge  for  topics  relevant  to  the 
successful  creation  and  execution  of  EA.  The  review  concluded  with  a  taxonomy  of 
concepts,  portrayed  in  the  aggregated  EA  best  practices  of  vision,  identification, 
framework,  and  governance. 

Within  the  context  of  EA  best  practices  attributing  to  alignment,  vision  refers  to 
the  definition  of  an  organization’s  strategy,  depicting  how  IT  will  be  used  in  support  of 
that  strategy.  Organizations  utilize  an  operating  model,  consisting  of  a  detennined 
amount  of  process  integration  and  process  standardization,  as  a  method  to  define  the 
vision  for  the  enterprise.  Identification  consists  of  capturing  the  capabilities  of  the 
organization’s  processes  as  well  as  their  IT.  Through  identification,  organizations  assess 
the  maturity  of  their  architecture  and  detennine  how  to  steer  their  IT  to  accommodate  it. 
Such  identification  can  include  application  licensing,  server  utilization,  networking 
requirements,  commercial  services,  and  data  management.  The  framework  best  practice 
refers  to  the  application  of  a  defined  architectural  framework  towards  the  capturing  of  an 
organization’s  processes  and  IT.  In  a  consistent  manner,  the  framework  ensures 
accountability  of  the  many  perspectives  that  exist  within  an  enterprise  and  captures  the 
relationships  shared  amongst  its  vast  resources.  Governance  represents  the  creation  of  a 
proper  enterprise  environment,  where  EA  is  allowed  to  work  for  the  organization. 
Aspects  of  effective  governance  are  management  commitment  towards  the  use  and 
creation  of  EA  as  well  as  the  realization  and  support  for  the  capabilities  of  IT  to  leverage 
mission  accomplishment.  Interestingly,  the  best  practices  identified  by  the  literature 
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review  relate  to  an  Enterprise  Architecture’s  depiction  of  the  “to  be”  target  state,  the  “as 
is”  baseline,  the  tools  and  models  used  for  communication,  and  the  motivation  and 
management  of  the  “transition”  plan. 

2.  What  Air  Force  policy  and  guidance  prescribes  and  describes  Enterprise 

Architecture  usage? 

The  first  instance  of  policy  directing  EA  use  within  the  Federal  Government  was 
created  in  1996  with  the  Clinger-Cohen  Act.  Since  that  time,  a  considerable  amount  of 
attention  has  been  directed  towards  EA  resulting  in  a  constellation  of  policy  and  guidance 
regarding  its  use  and  execution.  The  opening  of  Chapter  III  identifies  the  applicable 
policies  and  guidance  that  describe  and  prescribe  the  use  of  EA  within  the  Air  Force. 

Throughout  the  identification  of  applicable  policies  and  guidance,  an  area  for 
discussion  concerned  the  distinction  of  which  level  of  policy  was  applicable  to  whom  and 
which  was  not.  The  sheer  amount  of  policy  and  guidance  within  the  area  of  EA 
contributes  to  a  complicated  set  of  convoluted  processes  making  its  effective 
accomplishment  seem  impossible.  To  simplify  matters,  a  clarifying  distinction  can  be 
made  that  a  particular  architecture  effort  is  only  required  to  comply  with  the  level  of 
guidance  that  governs  their  use  of  EA.  Ensuring  the  alignment  and  federation  of 
subsequent  enterprises  in  accordance  with  higher-level  guidance  and  governance  is  the 
responsibility  of  an  owning  architecture.  For  instance,  a  program  level  architecture  such 
as  the  one  described  by  the  USAFE  TMT  solution  complies  and  aligns  with  its  owning 
MAJCOM  policies  regarding  architecture  certification  and  approval.  The  next  level  of 
applicability  is  the  responsibility  of  the  owning  MAJCOM  or  domain  level  architecture, 
which  in  this  case  is  the  USAFE  enterprise,  to  ensure  subsequent  enterprises  comply  and 
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align  with  AF  EA  policies  and  governance,  which  they  pursue  through  specified  channels 
for  certification  and  approval. 

It  is  also  important  to  note  different  organizations  utilize  different  or  varying 
degrees  of  multiple  frameworks.  An  example  of  this  can  be  seen  within  the  AF  EAF. 

The  AF  EAF  creates  its  own  distinct  framework  characteristics  while  also  leveraging 
aspects  of  DoDAF  and  FEAF.  Pinpointing  the  aspects  of  the  assigned  framework  also 
helps  with  simplifying  the  large  amounts  of  EA  guidance. 

3.  Does  the  Air  Force  Enterprise  Architecture  policy  and  guidance  adequately 

capture  the  concept  of  alignment? 

Despite  the  amount  of  years  contributed  towards  EA  work  and  regardless  of  the 
time  and  effort  associated  with  the  creation  of  the  prescriptive  and  descriptive  policy  and 
guidance,  all  levels  of  the  Federal  Government  routinely  receive  low  EA  effectiveness 
rankings  (US  GAO  2002;  US  GAO  2008).  This  issue  provided  the  motivation  for  the 
Chapter  III  analysis  of  EA  guidance  and  policy  on  the  DoD’s  ability  to  capture  the 
essence  of  alignment  represented  by  the  taxonomy  of  the  EA  best  practices.  As  the 
achievement  of  such  policy  and  guidance  seeks  to  “effectively  establish  and  leverage 
enterprise  architecture  as  instruments  of  organizational  transformation,”  the  results  of  the 
analysis  acknowledged  several  identifiable  gaps  (US  GAO  2008). 

The  gaps  identified  by  the  analysis  revealed  that  the  majority  of  the  Air  Force’s  IT 
is  not  driven  by  an  EA.  In  regards  to  the  vision  best  practice,  the  AF  operates  within  an 
IT  operating  model  focused  primarily  on  the  integration  of  processes  and  systems, 
resulting  in  IT  only  responding  reactively  to  the  integration  of  new  and  existing  systems 
and  processes.  By  actively  defining  and  pursuing  an  EA  vision  that  not  only  focuses  on 
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integration,  but  process  standardization  as  well,  will  allow  IT  to  be  leveraged  proactively 
in  the  pursuit  of  mission  accomplishment. 

The  identification  of  the  Air  Force’s  IT  and  processes  uncovers  an  enterprise 
where  perfonnance  is  locally  maximized  and  where  IT  does  not  drive  or  restrain  IT 
implementation.  The  ability  to  identify  an  architecture’s  level  of  maturity  allows  for  the 
assessment  of  associated  benefits,  which  come  with  that  particular  level  of  maturity,  to 
ensure  they  are  consistent  with  the  chosen  EA  vision.  Comparing  the  characteristics  of 
this  best  practice  with  the  deliverables  of  EA  use  described  by  the  AF  guidance  and 
policy,  this  is  not  where  the  AF  wishes  to  be.  Providing  additional  reason  to  pursue  a 
greater  level  of  architectural  maturity  is  the  ability  to  realize  greater  IT  efficiency  through 
cost-effectiveness  and  reliability,  a  solid  data  and  process  platfonn,  and  a  reprieve  from 
the  large  cost  associated  with  legacy  systems  (Ross  et  al.  2006). 

Frameworks  are  evident  throughout  AF  policy  and  guidance.  Their  purpose 
“provides  the  logical  structure  for  classifying,  organizing,  and  relating  the  breadth  and 
depth  of  infonnation  that  describes  and  documents  the  Air  Force  Enterprise 
Architecture,”  which  is  consistent  with  the  framework  best  practice  (AF  CIO  2003). 
Focusing  directly  on  a  framework’s  purpose,  the  AF  EAF  supports: 

•  Alignment  of  requirements  for  infonnation  systems  with  the  processes  that 
support  the  AF  missions 

•  Adequate  AF,  Joint,  and  combined  interoperability 

•  Integration,  assurance  and  security  of  infonnation  systems 

•  Prioritized  allocation  of  resources  to  critical  capabilities 
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•  The  application  and  maintenance  of  a  set  of  standards  by  which  the  AF  evaluates 
and  acquires  new  systems  (AF  CIO  2003) 

Throughout  the  referenced  guidance,  the  designation  of  “governance”  was  commonly 
used  to  refer  to  the  oversight  of  EA  use  as  well  as  to  describe  its  apparent  benefits. 
However,  absent  from  this  depiction  of  “governance”  is  an  EA  endorsing  environment 
consisting  of  allocated  resources,  management  importance,  or  the  need  for  culture 
change.  Best  practices  describe  governance  structures  to  consist  of  IT  investment 
management  processes,  communication  strategies,  ownership,  and  accountability.  To 
progress  past  the  current  ineffectiveness  of  EA  within  the  Federal  Government,  the  GAO 
recommends: 

The  key  to  having  a  mature  architecture  program,  and  thereby  realizing  the 
benefits  of  an  architecture-centric  approach  to  IT  investment  decision  making,  is 
sustained  executive  leadership.  This  is  because  virtually  all  of  the  barriers  to 
effectively  developing  and  using  architectures,  such  as  parochialism,  cultural 
resistance,  adequate  resources,  and  top  management  understanding,  can  be 
addressed  through  such  leadership  (US  GAO  2008). 

An  attitude  focused  towards  allowing  EA  to  work  for  an  organization  is  consistent  with 

the  governance  best  practice.  This  factor  appears  to  be  most  lacking  amongst  the  AF 

policy  and  guidance.  An  EA  attitude  supporting  the  AF  policy  and  guidance  needs  to  be 

fueled  with  commander’s  intent  in  order  to  facilitate  the  alignment  of  IT  with  mission, 

not  with  just  words  of  guidance,  but  with  action. 

Chapter  IV  described  a  case  study  representing  the  depiction  of  a  typical,  large- 

scale  deployment  of  an  enterprise  software  application.  The  portrayal  of  alignment 

represented  by  this  real-world  scenario  complements  the  descriptive  trend  of  this  research 

by  presenting  the  applicable  nature  of  these  best  practices,  creating  a  self-actualization  of 
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alignment’s  inherent  benefits.  Providing  additional  insight,  the  case  study  allowed  for 
several  important  realizations  regarding  the  applicability  of  the  EA  best  practices. 

Concerning  the  application  of  the  best  practice  vision,  the  case  study  showed  that 
perhaps  a  committed  EA  vision  does  not  have  to  be  structured  around  a  formal  product. 
While  the  vision  is  important  for  driving  the  implementation  of  IT  in  an  organization,  its 
existence  can  be  interpreted  as  a  result  of  other  initiatives.  In  the  case  of  USAFE,  their 
strategic  plan  served  as  the  basis  for  their  EA  vision.  Their  ability  to  project  power  is 
structured  around  access,  which  calls  for  the  enablement  of  mission  accomplishment  as 
well  as  the  interoperability  of  capabilities.  These  concepts  were  applied  throughout  the 
implementation  of  the  TMT  project,  and  while  not  formally  identified,  they  served  as  the 
vision  behind  its  planning  execution. 

Another  realization  provided  by  the  USAFE  case  study  is  the  importance  of 
thoroughly  identifying  the  IT  and  processes  of  an  organization.  The  TMT  project  went 
through  great  lengths  to  ensure  the  current  task  management  process  was  identified. 
Utilizing  an  AFSO-21  process,  the  project  management  team  was  able  to  scrutinize  the 
efficiency  of  the  current  process  as  well  as  capture  its  key  players,  capabilities  and 
deficiencies  of  the  current  supporting  IT  and  use  that  infonnation  towards  establishing 
the  goals  for  the  solution  to  increase  visibility  and  efficiency.  The  application  of  the 
identification  best  practice  within  USAFE  possibly  illustrates  the  value  that  comes  from 
AF  initiatives  such  as  AFSO-21.  It  unquestionably  portrayed  how  capturing  one’s  IT  and 
processes  can  assist  with  achieving  alignment. 

The  value  of  applying  the  framework  best  practice  comes  with  the  consistent 
depiction  of  relationships  and  infonnation  within  an  organization.  The  USAFE  task 
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management  team  was  able  to  capture  these  entities  without  the  use  of  a  formally  defined 
framework  such  as  DoDAF  or  the  AF  EAF.  The  USAFE  team  used  experience,  insight, 
and  common  sense  to  depict  the  necessary  components  to  create  a  successful  project 
implementation.  However,  the  created  diagrams  do  not  provide  the  consistency  needed 
to  depict  integration  with  other  programs  or  enterprises.  A  similar  effort,  creating  its  own 
diagrams,  will  not  coincide  with  the  diagrams  used  by  the  TMT  project.  A  defined 
framework  facilitates  how  to  capture  the  Who,  What,  When,  Where,  Why,  and  How 
surrounding  a  process.  Since  a  specified  framework  provides  a  consistent  method  to 
capture  separate  processes  and  projects,  a  variety  of  diagrams  can  be  mapped  together  to 
illustrate  the  processes  and  systems  comprising  an  entire  enterprise. 

As  can  be  seen  by  the  USAFE  task  management  solution,  the  support  of 
leadership  contributes  to  the  success  or  failure  of  a  project.  The  USAFE  environment 
understood  the  case  for  fixing  the  inefficient  task  management  process  and  the  project 
management  team  was  allotted  the  necessary  organizational  freedom  and  resources  to  fix 
the  problem.  A  retrospective  look  at  the  TMT  project  demonstrates  how  their 
environment,  consisting  of  factors  from  the  governance  best  practice,  contributed  to  the 
project’s  success.  This  real-world  depiction  of  “sustained  executive  leadership”  is  a 
representation  of  the  necessity  for  leadership  to  convey  a  similar  type  of  sustainment 
towards  EA  use  to  create  an  environment  where  EA  benefits  the  Air  Force  (USGAO 
2008). 
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Recommendations 


As  stated  in  the  EA  guidance  analysis  of  Chapter  III,  the  policy  and  guidance 
surrounding  EA  use  is  abundant.  Lacking  from  this  policy  and  guidance  is  the  allocation 
of  resources,  management  importance,  or  the  need  for  culture  change.  Perhaps 
contributing  to  this  dilemma  is  that  it  takes  a  substantial  viewpoint  of  alignment  to  realize 
its  benefit  and  that  EA  in  and  of  itself  has  no  intrinsic  value.  Conceivably,  transposing 
the  benefit  of  EA  use  towards  its  positive  effects  on  other  processes,  such  as  IT  portfolio 
management,  modifies  the  focus  of  measurement  to  another  entity,  possibly  allowing  for 
a  realization  of  its  value.  Case  studies  have  shown  alignment  attributing  to  enhancements 
for  the  private  sector,  however,  these  enhancements  contain  factors  such  as  growth, 
competitive  enhancements,  and  affecting  the  bottom  line,  which  are  not  a  primary 
concern  of  the  public  sector. 

The  Decision  Analysis  approach  of  value-focused  thinking  (VFT)  could  be  used 
to  assist  with  quantifying  value  for  DoD  EA  use.  VFT  elicits  the  desired  objectives  from 
a  decision  maker  to  apply  critical  thinking  towards  one’s  values  or  what  are  believed  to 
be  important  factors  in  a  decision.  This  process  helps  the  decision  maker  detennine  their 
values  concerning  a  decision,  develop  objectives  based  on  these  values,  and  structure 
them  to  detennine  the  trade-offs  between  competing  or  conflicting  objectives.  VFT 
could  be  used  to  capture  an  “importance”  weight  of  the  four  best  practices  as  applied  to 
an  IT  project.  Associating  value  to  the  four  best  practices,  the  decision  maker  could 
further  actualize  alignment’s  inherent  benefits  and  additionally  promote  an  appreciation 
for  EA  efforts. 
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Some  of  the  guidance  described  and  analyzed  within  Chapter  III,  such  as  DoDAF, 
AFPD  33-4,  and  AFI  33-401,  are  in  the  process  of  being  updated.  Future  research  efforts 
could  assess  the  achievement  of  alignment  within  the  new  concepts  represented  amongst 
these  updates.  Additional  case  studies  could  also  be  developed  to  analyze  IT  projects 
and  EA  efforts  on  their  ability  to  capture  alignment.  These  case  studies  could  possibly  be 
used  towards  associating  the  need  for  an  EA  program  in  order  to  achieve  alignment.  The 
best  practices  identified  by  this  research  are  associated  with  alignment;  they  can  be  used 
to  guide  future  implementations  of  IT  projects  and  EA  efforts,  as  well  as  retrospectively 
assess  mission  accomplishment. 
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Appendix  A:  Definition  of  Terms 


Acronyms 

AF 

Air  Force 

AFEAF 

Air  Force  Enterprise  Architecture  Framework 

AFI 

Air  Force  Instruction 

AFPD 

Air  Force  Policy  Directive 

AFSO-21 

Air  Force  Smart  Operations 

AO 

Action  Officers 

CCA 

Clinger-Cohen  Act  of  1996 

CIO 

Chief  Infonnation  Officer 

CJCSI 

Chainnan  of  the  Joint  Chiefs  of  Staff  Instruction 

CRM 

Customer  Relations  Management 

DAF 

Department  of  the  Air  Force 

DARS 

DoD  Architecture  Registry  System 

DoD 

Department  of  Defense 

DoDAF 

DoD  Architecture  Framework 

DoDD 

Department  of  Defense  Directive 

DS 

Director  of  Staff 

EA 

Enterprise  Architecture 

E-Gov 

E-Government 

EIM 

Enterprise  Infonnation  Management 

FEA 

Federal  Enterprise  Architecture 

FEAF 

Federal  Enterprise  Architecture  Framework 

GIG 

Global  Infonnation  Grid 

HQ 

Headquarters 

IT 

Information  Technology 

MAJCOM 

Major  Command 

NCOIC 

Non-Commissioned  Officer  in  Charge 

NSS 

National  Security  Systems 

OCR 

Office  of  Collateral  Responsibility 

OMB 

Office  of  Management  and  Budget 

OPR 

Office  of  Primary  Responsibility 

RFI 

Request  for  Information 

SME 

Subject  matter  experts 

TBM 

Theater  Battle  Management 

TMT 

Task  Management  Tool 

USAFE 

United  States  Air  Forces  of  Europe 

VFT 

Value  Focused  Thinking 
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